Fix clear detection mistake #13327
Fix clear detection mistake #13327
Conversation
The check was reversed before, oops. Detected masked draws. Must've gotten this backwards debugging Mana Khemia.
This means a framebuffer texture that is somehow not attached, but better to avoid the crash.
|
Nice! Those masks are tricky heh. Let's try it. |
|
I think this might have fixed the 'menu' problem in 3rd birthday in retroarch. I just tried it on a GLES retroarch build (but on the desktop, it's the only way i can run ppsspp libretro) with the frameskip gone and no weird judder apparent. |
|
If it fixed a retroarch-only bug, it probably means something like function replacements are being forced off in retroarch. -[Unknown] |
|
Well, some of our replacements would do something this commit also can do. -[Unknown] |
|
Ah I got you. I'll make a bisect to make sure then open a bug report. I'm pretty sure that i'm placing the files in the right dir but maybe it's a question of having renamed the retroarch 'system' dir from its default 'system' name to 'bios' (i did it ages ago in retroarch.cfg and never changed), and the ppsspp core part trying to read from hardcoded 'system'. |
|
Whats the name of the function replacements file in the assets, 'compat.ini'? |
|
You're probably thinking of knownfuncs.ini, but that file is not used by default and not required for function replacements. The list of function hooks are compiled into PPSSPP and enabled normally by an ini setting. No assets are needed. -[Unknown] |
|
I was mistaken it was 5313fc5 that fixed it. Possibly only on opengl, but maybe the last vulkan fix takes care of that too (i don't have a vulkan capable gpu). |
|
This change somehow caused #13344 as a side effect. |
|
Hm, likely from #12952 then ultimately - this fixes a typo in that. Hm. Maybe the game does a block transfer into the current target or something? But we'd detect that. If it really is a full screen sprite, how could that overwrite the wrong memory? I suppose we don't check scissor X1/Y1... -[Unknown] |
Fixes #13320, was just a mistake in 1432cc9.
It's possible this may re-break #12858 because it may have been incorrectly setting the safe size when it was not, in fact, safe. That said, I think it'll still work.
-[Unknown]